【AWS DevDay Tokyo 2019 セッションレポート】40分で分かるDynamoDBでのApp開発 #awsdevday
AWS DevDay Tokyo 2019のセッション、「40分で分かるDynamoDBでのApp開発」をレポートします。
セッション概要
Amazon DynamoDBはフルマネージドサービスで提供されるkey-value およびドキュメントデータベースです。世界中でもAmazonを始め多くのユーザーに利用されており、是非このセッションでDynamoDBを利用した開発の導入部分を学んで頂きたいと考えています。 本セッションではpythonで書かれたサンプルアプリを例として主要なデータ操作、よく比較されるRedisとのユースケースでの使い分けなどを解説します。 是非アプリケーション開発でDynamoDBを導入する手助けになれば幸いです。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社
ソリューションアーキテクト
成田 俊(@oranie)さん
セッション内容
Introduction to Amazon DynamoDB
- フルマネージド
- ハイパフォーマンス
- エンタープライズ対応
Enterprise DevOps: Why You Should Run What You Build
You build it, you run it
メンテナンスフリー
これらを管理するコストがなければ他に何ができる?→DynamoDBを使えばAWSに任せることができる
- セキュリティ
- 耐久性
- 可用性
- 性能
- 拡張性
Table構造
- Table
- Item
- Attributes
- Partition Key/Sort Key以外は必須ではない
- Partition Key
- データの分布を決定
- Sort Key
- 1: Nのrelationship
- Queryによる幅広い探索で利用
- Sort KeyとPartition Keyの組み合わせでユニーク性を担保
- Attributes
- Item
NoSQL Workbench for Amazon DynamoDB(preview)
- operation builder
- python Javaのコード生成機能がある
Sample App解説
リアルタイムコメント欄
デモアプリ
APIGateway - Lambda - DynamoDB
Chaliceで作成
必要な機能
- コメント書き込み
- 25件コメント取得
- 全てのコメントを取得
- 時系列位置を指定して取得
Redisで実現するなら
- Stream型XAA,XRANGE,XREVRANGEを使うと実装できそう
- SortedSetでも実現は可能
DynamoDBで実現するなら
- DynamoDBの特性を活かし、より書き込みに対してスケーラブルなパターンを今回想定
モデリング解説
- Table
- name PK
- Time sortkey
- comment
- Chatroom
- GSI
- timeを sortkey
- ChatroomをPK
- 初めからGSI側のモデリングで良いのでは?
- 書き込みが少ない時は問題ないが、多くなると書き込み箇所が一点に集中し遅くなるおそれ
- 読み込みが増えてきたらGSIをDynamoDBStreamsとRedisを組み合わせて負荷をオフロード可能
デモについての簡単な解説
- コメント書き込む
- Putties existing check付与
- 最新25件コメント取得
- Query chatroom id指定かつ時系列降順25件
- 全てのコメント取得
- Query 全件取得
- 位置を指定して取得
- Query 〜以上という処理を入れる
- コード解説
- コメント作成
- ReturnValues
- ReturnConsumedCapacity
- ExpressionAttributeNames
- ConditionExpression
- 最新コメント取得
- インデックス名を指定
- ScanIndexForward
- Limit
- 範囲でコメント取得
- KeyConditionExpressでgt()
- LastEvaluatedKey
- ExclusiveStartKey
- 全コメントを取得
- チャットルーム指定
- リミットなし
- コメント作成
- Redisとの組み合わせパターン
- DynamoDBStreamでLamdba起動
- 同い値をRedisに書き込む
- 参照系をRedisにする
CIをどうするか
- 一番簡単なのは全てAWSのリソースを使うこと
- 外部CIサービスを使う場合、どうやって権限渡すか
- 複数のテストが同時に同じテーブルを使うかも
解決案1
- Tableをbuild projectごとに分ける
- 並列に実行されるbuildが少なければ問題なし
- 多いとアカウントあたりのlimitに抵触するかも
解決案2
- DynamoDB localを使う
- 課金の心配なし
- 外部のCIサービスでも使える JAR or コンテナ
- STGのリリースからDynamoDB(not local)を使い始める
DynamoDB local使用CI(テスト)例
- CodeBuildのコード例
- CircleCIのコード例
- Github Actionのコード例
まとめ
- Item 操作の記述に迷ったらNoSQL Workbench for Amazon DynamoDB
- DynamoDB Streamsを組み合わせて他のサービスと連携
- DynamoDB localを活用してCI、テスト
- DynamoDB公開レビュー 10/24@AWS Loftがあるので是非きてください
QA
ElastiCacheとDynamoDBの使い分け
- 永続性が求められるものはDynamoDB
- レスポンスはElastiCache(Redis)の方が早いことが多い
- DAXは?
- DynamoDBとRedisにダブルリード、ライトするところをDAX一回だけにできる利便性
感想
サンプルコードが豊富で、デモアプリも具体的だったのでとても勉強になりました!